home *** CD-ROM | disk | FTP | other *** search
Text File | 2002-10-08 | 45.6 KB | 1,254 lines |
-
-
-
- - 1 -
-
-
-
- 7.3.1.3m for IRIX 6.5.18 Base Compiler Execution Environment Release Notes
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 2 -
-
-
-
- 1. _B_a_s_e__C_o_m_p_i_l_e_r__E_x_e_c_u_t_i_o_n__E_n_v_i_r_o_n_m_e_n_t
-
- These release notes describe the MIPspro 7.3
- release and its maintenance update 7.3.1.3m for
- IRIX 6.5.18 of Silicon Graphics(TM) IRIX(TM)
- compiler execution environment (EOE)
- (compiler_eoe). The IRIX compiler EOE contains
- compiler execution utilites such as rld and base
- compiler run-time libraries supplied as DSOs
- (dynamic shared objects). DSOs are discussed in
- the dso(5) man page. The IRIX compiler EOE
- supports MIPSpro compilers in either 64-bit,
- 32-bit, or high performance 32-bit (n32)
- compilation modes. For more information about
- 64-bit and high performance 32-bit interfaces,
- see the _M_I_P_S_p_r_o _6_4-_b_i_t _P_o_r_t_i_n_g _a_n_d _T_r_a_n_s_i_t_i_o_n
- _G_u_i_d_e and the _M_I_P_S_p_r_o _N_3_2 _A_B_I _H_a_n_d_b_o_o_k.
-
- If you plan to run any IRIX applications, it is
- important to note that you must install the IRIX
- compiler EOE.
-
- Packaged with this software is a separate
- Software License Agreement. This software is
- provided to you solely under the terms and
- conditions of the Software License Agreement.
- Please take a few moments to review this
- agreement.
-
-
-
- 1.1 _R_e_l_e_a_s_e__I_d_e_n_t_i_f_i_c_a_t_i_o_n__I_n_f_o_r_m_a_t_i_o_n
-
- Following is the release identification
- information for the IRIX compiler EOE
- (compiler_eoe):
-
- Software product IRIX compiler EOE
-
- Release 7.3.1.3m for IRIX
- 6.5.18
-
- Product code IDEVFNT-1.2
-
- System software requirements IRIX 6.5.18
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 3 -
-
-
-
- 1.2 _O_n_l_i_n_e__R_e_l_e_a_s_e__N_o_t_e_s
-
- After you install the online documentation for a
- product (the relnotes subsystem), you can view
- the release notes on your screen.
-
- If you have a graphics system, select Release
- Notes from the Help submenu of the Toolchest.
- This displays the grelnotes(1) graphical browser
- for the online release notes. For information
- on options to this command, refer to the
- grelnotes(1) man page.
-
- If you do not have a graphics system, you can
- use the relnotes command. For information on
- accessing the online release notes using this
- command, refer to the relnotes(1) man page.
-
-
- 1.3 _P_r_o_d_u_c_t__S_u_p_p_o_r_t
-
- Silicon Graphics provides a comprehensive
- product support maintenance program for its
- products.
-
- If you are in the United States or Canada and
- would like support for your Silicon Graphics
- supported products, contact the Customer Support
- Center at 1-800-800-4SGI.
-
- If you are outside the United States or Canada,
- contact the Silicon Graphics subsidiary or
- authorized distributor in your country.
-
-
-
- 1.4 _I_n_s_t_a_l_l_a_t_i_o_n__I_n_f_o_r_m_a_t_i_o_n
-
- If you are installing this option for the first
- time, to install the subsystems marked default,
- use the go menu item. To install a different
- set of subsystems, use the following commands in
- inst to customize the list of subsystems to be
- installed:
-
- +o install
-
- +o remove
-
- +o keep
-
-
-
-
-
-
-
-
-
-
-
-
- - 4 -
-
-
-
- +o step
-
- Then select the go menu item.
-
-
- 1.5 _S_u_b_s_y_s_t_e_m_s
-
- The IRIX compiler EOE software (compiler_eoe)
- for MIPSpro 7.3 includes the following
- subsystems:
-
- compiler_eoe.man.relnotes IRIX compiler
- execution environment
- release notes
- (default)
-
- compiler_eoe.man.dso IRIX DSO man page
- (default)
-
- compiler_eoe.man.unix IRIX standard man
- pages (default)
-
- compiler_eoe.sw.cpp Source code
- preprocessor
- (default)
-
- compiler_eoe.sw.lboot Kernel lboot software
- (default)
-
- compiler_eoe.sw.lib Base compilers
- execution libraries
- (default)
-
- compiler_eoe.sw.unix IRIX execution
- environment
- (compiler) (default)
-
- compiler_eoe.sw64.lib Base compilers
- execution libraries
- (64-bit) (default on
- R8000(TM) and
- R10000(TM) systems
- only)
-
- compiler_eoe.sw64.unix IRIX execution
- environment ( 64-bit
- compiler) (default on
- R8000 and R10000
- systems only)
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 5 -
-
-
-
- 1.6 _B_u_g_f_i_x_e_s__i_n__7_._3_._1_._3_m__f_o_r__I_R_I_X__6_._5_._1_8_
-
- 846339 Pthread C++ code with exception
- handling hang
-
- 858299 Rqs fails with new libc allocation on
- unix98
-
-
- 1.7 _B_u_g_f_i_x_e_s__i_n__7_._3_._1_._3_m_
-
- 770106 The file
- /usr/relnotes/compiler_eoe/chA.z has
- size 0. This has been fixed.
-
- 777196 Gaussian problem with policy module
- table.
-
- A customer running Gaussian98 on IRIX
- 6.5.x reports a problem with MLD
- creation. The error returned is:
-
- Could not create MLD: Not enough space
-
- This has been fixed.
-
- 804796 libmp coredumps with OMP_NUM_THREADS ==
- 256. This has been fixed.
-
-
- 822823 F90: acos returns NaN.
-
- The program below prints NaN instead of
- pi for the variable z. This was first
- observed with the Fortan 90 MIPSpro
- 7.3.1.2 compiler. This occured when
- the program was compiled -n32 and -64.
- If variables a and b are declared
- real*16, then variable z is correct.
-
- program test
- real*8 a,b
- real*16 x,y,z
- a = 4.
- b = 1.
- x = a * atan(b)
- y = cos(x)
- z = acos(y)
- print *, x, y, z
- end program test
-
-
-
-
-
-
-
-
-
-
-
-
- - 6 -
-
-
-
- This has been fixed.
-
- 821769 Significant performance loss running
- ADA apps in 6.5.10. This has been
- fixed.
-
-
- 834590 The .dynamic section of the a.out now
- has entries for the timestamp and
- checksum. This allows downstream tools
- such as SpeedShop to determine if data
- files match the executable or not. This
- information has always been in dsos.
-
- Warning: a recompiled a.out will now
- always have different bits.
-
-
- 819091 The linker generates some text on it's
- own such as the init and fini function
- driver. Up to now the linker neglected
- to generate debugging information along
- with this text making unwinding in the
- debugger and exception handling
- routines problematic. This has been
- fixed.
-
- There are still problems with unwinding
- through linker generated code that has
- been instrumented for performance
- evaluation. This will be addressed
- later.
-
-
-
- 1.8 _B_u_g_f_i_x_e_s__i_n__7_._3_._1_._2_m
-
- 778798 rld was broken for purify on pthread
- applications, and the purified
- pthreaded app could coredump.
-
- 783179 rqs/rqs32/rqs64 did not process the
- multigot dynamic section extensions of
- multigot executables or DSOs correctly
- (see man ld, man dso). The error was
- harmless but could be distressing on a
- multigot executable (rqs could coredump
- processing netscape 4.72, for example,
- but the coredump would NOT harm
- netscape). If rqs did not core dump on
- a multigot shared library (DSO) it
-
-
-
-
-
-
-
-
-
-
-
- - 7 -
-
-
-
- processed, rqs could corrupt the DSO
- (if and only if rqs was attempting to
- 'move' the DSO to a new address and
- terminated normally: if rqs coredumped
- then the DSO it was processing is
- safe). There are very few multigot
- DSOs: /usr/lib64/libInventor.so.3 is
- one such. Once damaged, a DSO is not
- repairable, but must be reinstalled.
- [If "elfdump -L myfile | grep AUX_DYN"
- shows a line or more of output then
- <myfile> is multigot.]
-
- 770775 n32, 64 libexc.so The
- trace_back_stack() and/or exc_unwind()
- functions could get mixed up and not
- trace back successfully in programs
- using pthreads. Now fixed.
-
- 770782 n32, 64 libexc.so The exc_unwind()
- function was not setting sigcontext pc
- to 0 always. A prudent application
- will also check for a sigcontext pc <
- 4 and stop, though the library bug is
- fixed.
-
- 770785 n32, 64 libexc.so The exc_unwind()
- function was not unwinding past
- sigtramp(). Fixed.
-
- 761433 n32, 64 libexc.so If dbx or WorkShop
- had set a frame_exit_trap in a routine
- on the stack, functions such as
- trace_back_stack() did not work
- correctly because of the details of the
- implementation of dbx/WorkShop frame
- exit traps. Fixed libexc.so to deal
- with this situation so the traceback
- works.
-
- 792734 o32 libexc.so The floating point
- registers were being picked up
- incorrectly from memory when libexc
- unwound the stack. libexc was not
- reflecting the o32 ABI register save
- rules during the restoration. Now this
- works correctly.
-
- 673119 rld -ignore_version did not work when
- -delay_load was used in earlier 7.3
- releases. Fixed.
-
-
-
-
-
-
-
-
-
-
-
- - 8 -
-
-
-
- 678896 _RLDN32_LIST processing could be wrong
- if "" was used as the environment
- variable value to turn off _RLDN32_LIST
- when _RLD_LIST was set for o32. Fixed.
-
- 780001 32-bit Log function returns incorrect
- results. This has been fixed.
-
- 801546 Mips4 version of libfastm gives
- incorrect results on R5000.
-
-
-
-
- 1.9 _B_u_g_f_i_x_e_s__i_n__7_._3_._1_._1_m__(_a_n_d__7_._3_._1_m_)
-
-
- The MIPSpro 7.3 Compiler Execution Environment
- for IRIX 6.5.x consisted of runtime libraries
- that contained daddiu instructions that could
- encounter an arithmetic overflow under certain
- circumstances. An errata in revision 4 or
- earlier of MIPS R4000 and R4400 would cause
- incorrect answers to be produced when
- encountering arithmetic overflows in executing
- the daddiu instruction.
-
-
- To see what processors are on your system,
- use the hinv command:
-
- Example:
-
- % hinv
- Processor 12: 100 MHZ IP19
- CPU: MIPS R4400 Processor Chip Revision: 4.0
- FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
-
- In the example, the Revision 4.0 processor does have the
- daddiu instruction errata.
-
-
- Although no demonstrable bugs have been found in
- the base compiler runtime libraries, they also
- have been recompiled, so as not to use the
- daddiu instruction in cases where arithmetic
- overflow can happen.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 9 -
-
-
-
- 1.10 _B_u_g_f_i_x_e_s__i_n__7_._3
-
- The following sections describe bugs that have
- been fixed since the MIPSpro 7.2.1 release.
-
-
- 1.10.1 _B_u_g_s__F_i_x_e_d__i_n__l_i_b_m
-
- The following libm bugfixes have been applied
- from patchSG0003131 into compiler_eoe 7.2.1.1m
- for IRIX 6.5.1m:
-
- 591738, 594226, 595879 Under certain inputs,
- sin() returns wrong
- results on systems
- running on the
- R5000(TM) CPU.
-
-
-
- 1.10.2 _B_u_g_s__F_i_x_e_d__i_n__l_i_b_m_p
-
- The following libmp bugfixes have been made in
- compiler_eoe 7.2.1.3m/f for IRIX 6.5.3m/f:
-
- 658799 libmp.so is not cpr
- compliant in IRIX
- versions 6.5.[2,3].
-
- 638713 Various routines
- invoke mp_numthreads,
- disabling dynamic
- threads in IRIX 6.5.
-
- 657207 Cannot change number
- of threads between
- parallel regions with
- version 7.3
- compilers.
-
- The following libmp bugfixes have been made in
- compiler_eoe 7.2.1.2m/f for IRIX 6.5.2m/f:
-
- 554156 Use of the
- environment variable
- MP_SLAVE_STACKSIZE
- leads to
- unpredictable
- results.
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 10 -
-
-
-
- 560707 Fortran MP programs
- (sproc) with
- unlimited stack sizes
- fail.
-
- 587240 A performance
- degradation occurs
- when OMP_DYNAMIC is
- set and the program
- is run under Miser.
-
- 599609 libmp MLD information
- is incorrect on 128
- CPUs.
-
- 610654 In OpenMP, a barrier
- within the dynamic
- extent of a parallel
- do receives a
- misleading error
- message at run time.
- In particular, a
- barrier is a
- synchronization
- construct, not a
- worksharing
- construct.
-
- 587240 When using the
- _DSM_MUSTRUN flag and
- a node has only one
- CPU and a process
- gets scheduled to run
- on that node, libmp
- attempts to place a
- process on a non-
- existent processor.
-
- The following libmp bugfixes have been applied
- from patchSG0003139 into compiler_eoe 7.2.1.1m
- for IRIX 6.5.1m:
-
- 581775 The OpenMP directive,
- schedule(static,ichunk),
- ignores ichunk.
-
- 581835 The OpenMP directive,
- ORDERED
- schedule(dynamic,ichunk),
- deadlocks if ichunk
- is not equal to
-
-
-
-
-
-
-
-
-
-
-
- - 11 -
-
-
-
- n/nprocs.
-
- 590252 Program with the
- OpenMP ORDERED
- directive deadlocks
- under some
- conditions.
-
-
- 1.10.3 _B_u_g_s__F_i_x_e_d__f_o_r__r_l_d__a_n_d__r_q_s The
- following rld and rqs bugs have been fixed since
- the 7.2.1.2m release of compiler_eoe for IRIX
- 6.5.2m:
-
- 608296, 641687, 641192 Various performance
- improvements have
- reduced CPU time
- spent in rld (in
- small ways).
-
- 426852 By default, rld no
- longer reevaluates
- name bindings on
- dlclose(). (The
- _RLD_ARGS -f argument
- also uses this new
- default behavior).
- This fix makes
- dlclose() fast and
- eliminates many
- lazy-text-resolves.
- It also affects the
- operation of programs
- that rely on names
- being rebound to a
- different
- function/data item
- after a dlclose().
- Such programs are
- erroneous. If the -s
- option is present
- with _RLD_ARGS, the
- old slow method of
- dlclose is used (this
- is provided for
- erroneous programs
- that depend on the
- old method). Details
- are as follows:
-
- Each name SHOULD be
-
-
-
-
-
-
-
-
-
-
-
- - 12 -
-
-
-
- bound only once by
- rld, but in
- complicated
- circumstances, names
- can be rebound. If
- the result of
- application actions
- (like dlclose()) is
- that the rebinding
- finds a different
- external definition,
- the result can be
- application problems
- or an application
- crash (rld does not
- realize this has
- happened and will not
- give a warning). (In
- addition, having a
- weak name defined in
- one DSO and a strong
- version in a DSO
- loaded later leads to
- 'undefined name
- bindings' and
- potentially
- inconsistent
- application behavior.
- This has always been
- true but not
- mentioned earlier.
-
- 644389 If an application did
- an sgidladd() or
- dlopen(...RTLD_GLOBAL),
- followed by a
- dlopen(...RTLD_LOCAL)
- (and the call to
- sgidladd/dlopen(...RTLD_GLOBAL)
- was itself done from
- a DSO that was opened
- or added by a dlopen
- or dladd command),
- name lookups by rld
- might not find names
- made global by the
- sgidladd() or
- dlopen(...RTLD_GLOBAL).
- This was a bug
- introduced in patch
- 3378.
-
-
-
-
-
-
-
-
-
-
-
- - 13 -
-
-
-
- 638915 If a DSO or
- executable file had
- more than 4096
- conflict symbols, rqs
- could core dump. Now
- the hash table
- definition allows up
- to 262,000+ conflict
- symbols. Although
- this is the maximum
- size allowed, if a
- smaller number will
- work, a smaller
- number is used.
-
- 649041 If a lazy-text-
- resolution call
- involved floating
- point argument
- registers and if a
- call in the -init
- code in the DSO
- loaded involved
- floating point
- registers, the lazy-
- text call fp argument
- registers would be
- destroyed by the
- -init arguments. Due
- to details of
- argument register
- passing, this bug is
- seen most readily
- with the n32/64 ABIs,
- though it can be
- reproduced in any of
- the ABIs.
-
- 651001 On delay-loads of
- DSOs, versions have
- been ignored for
- almost all earlier
- releases of rld. Now
- rld checks the
- version number on
- delay-loads too. The
- new _RLD_ARGS option
- -idv turns off DSO
- version checking for
- delay-loads in rld
- and rld.debug,
-
-
-
-
-
-
-
-
-
-
-
- - 14 -
-
-
-
- restoring the old,
- broken behavior.
-
- 630359 Debugger stack traces
- through rld sometimes
- stops in rld due to
- mistakes in some
- hand-written assembly
- code in rld. Now the
- stack traces show the
- callers back to
- main(), as
- appropriate.
-
- 629117 rld now obeys the
- general rule that
- processing is
- breadth-first
- (loading of DSOs from
- liblists and dlsym()
- name resolution are
- examples). Details
- are as follows:
-
- In the past, it did
- almost-breadth-first
- ordering. Because
- seeing an error in
- ordering required
- having duplicate
- symbol definitions at
- least 4 levels deep
- in DSO nested
- liblists, it is
- unlikely this bug
- affected any
- application. But the
- ABIs have always been
- clear and now rld
- obeys the ABIs.
-
- 629128 In the case of a
- dlclose(), all -fini
- execution is done for
- a set of DSOs (where
- this is the dlclose
- of the last
- reference) before any
- are unmapped.
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 15 -
-
-
-
- 629707 Nested
- dlopen/sgidladd/delay-
- load (that is,
- invoking
- dlopen/sgidladd/delay-
- load from within the
- -init or -fini code
- of a
- dlopen/sgidladd/delay-
- load) now works even
- in the pthreads and
- sproc threads cases.
- Nested
- dlopen/sgidladd/delay-
- load was always
- problematic (though
- if no pthreads or
- sproc threads were in
- use, it might have
- appeared to work, as
- long as none of the
- nested
- dlopen/sgidladd/delay-
- load failed).
-
- Use nested
- dlopen/sgidladd only
- when absolutely
- required. Use -init
- only when absolutely
- required, as the
- nested dependencies
- make static
- prediction of the
- ordering in which the
- -init code is to be
- run difficult.
-
- C++ global
- constructors ordering
- across compiliation
- units has always been
- unspecified by the
- C++ definition.
- Adding delay-load to
- the set of DSOs with
- mutual constructor
- calls makes the
- ordering even less
- predictable. Using
- or setting
-
-
-
-
-
-
-
-
-
-
-
- - 16 -
-
-
-
- sigprocmask(2) in
- -init or -fini code
- is not a good idea
- because the set of
- masks seen as ON is
- affected by rld. The
- precise behavior of
- sigprocmask(2) in
- -init or -fini code
- depends on which of
- 1) pthreads, 2) sproc
- threads, or 3)
- neither is in use.
- The details are not
- specified in these
- release notes; it is
- best to avoid setting
- or resetting the
- sigprocmask() in
- -init or -fini code.
- In addition, it is
- still difficult to
- debug -init code in
- the application
- startup.
-
- 634151 If the filesystem of
- a DSO had no XFS
- attributes, rqs could
- fail (refuse to
- update a DSO to allow
- quickstart) and fail
- to print the proper
- reason message. (The
- system would operate
- properly in spite of
- this rqs error.) Now
- rqs understands that
- ENOATTR is not really
- a failure, allowing
- the DSO to be
- quickstarted again,
- and uses strerror()
- to properly print all
- errno values when
- there is an error.
-
- 547873 rld got delay load
- DSO visibility
- slightly wrong in
- MIPSpro 7.2.1. Too
-
-
-
-
-
-
-
-
-
-
-
- - 17 -
-
-
-
- restrictive in symbol
- visibility.
-
- 648641 ssrun(1) could
- interact with rld,
- causing some -init
- functions to not run
- correctly. This fix
- corrects the rld
- part.
-
- Note: it is erroneous
- for a signal handler
- to call dlopen(),
- dlclose(),
- sgidladd(),
- sgidlopen_version(),
- dlsym(), or
- dlerror().
- Similarly, no
- function call in a
- signal handler is
- allowed to cause a
- delay-load of a DSO
- (this is an implicit
- dlopen and it is not
- correct). In fact,
- very few functions
- are legally callable
- from a signal
- handler. the dl*
- functions are not so
- callable. It is up
- to applications to
- ensure that such does
- not happen.
-
- The following bugs have been fixed since the
- 7.2.1.1m release of compiler_eoe for IRIX
- 6.5.1m:
-
- 549912 In rld there were
- potential deadlock
- and signal-mask
- handling problems.
-
-
- 554703 rld needs to emit a
- better message in
- case of bad
- DSO/executable file.
-
-
-
-
-
-
-
-
-
-
-
- - 18 -
-
-
-
- 558948 In rld, there was an
- incorrrect
- implementation of
- add_version_to_name().
-
-
- 568510 rqsall, under certain
- circumstances, falls
- into an infinite
- loop.
-
-
- 586353 A call occurs to a
- function defined by
- rld at 0xffffffff.
-
-
- 589044 An rld warning does
- not give the object
- name.
-
-
- 600777 rld incorrectly
- performs an alloca()
- in a loop.
-
-
- 604402 An rqsall manpage
- example does not
- work.
-
-
- 608753 The rld
- RHF_NO_LIBRARY_REPLACEMENT
- argument is not
- honored.
-
-
- 614133, 615089 rld is too large and
- could be smaller with
- its own vsnprintf.
-
-
- 615441 rld does extra
- useless lookups,
- degrading
- performance.
-
-
- 620471 An application that
- performs a dlopen
-
-
-
-
-
-
-
-
-
-
-
- - 19 -
-
-
-
- experiences slow
- performance due to
- poor string compare
- code.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-